v1.0.0 to v1.0.1

+ description: "Use when configuring grant tracking in a Salesforce nonprofit org: NPSP Outbound Funds Module (open-source outfunds managed package) or Nonprofit Cloud for Grantmaking (separate license). Trigger keywords: grant management, funding awards, disbursement tranches, grantmaking setup, OFM, FundingAward, FundingDisbursement, FundingAwardRequirement. NOT for recording donor gifts and receipts, use admin/gift-entry-and-processing. NOT for reporting program outcomes to a funder, use admin/program-outcome-tracking-design."

+ - "turn on Grantmaking and set up funding awards with disbursement schedules and report requirements"

+ - "block the next grant payment until the grantee's report is approved"

+ version: 1.0.1

+ updated: 2026-10-03

+ - **Which platform is installed?** Check Installed Packages for `npsp` (NPSP), `outfunds` (Outbound Funds Module), and the Grants Management managed package, and check Setup > Grantmaking Settings. These products do not share objects. Do not mix guidance between them.

+ - **Is Grantmaking licensed and turned on?** Grantmaking objects need the Grantmaking licence, the feature turned on, and the Manage Funding Awards system permission. Turning Grantmaking on cannot be undone (`references/gotchas.md`, Gotchas 1 and 2).

+ - **What is the disbursement model?** Single payment or scheduled tranches. Both products model tranches: `FundingDisbursement` in Grantmaking, `outfunds__Disbursement__c` in Outbound Funds.

+ - **Which deliverables gate which payments?** Both products have a requirement object that can point at a disbursement: `FundingAwardRequirement.FundingDisbursementId` and `outfunds__Requirement__c.Disbursement__c`. (Corrected: an earlier version said Outbound Funds has no deliverable-tracking object.)

+ ## Questions to Ask Before Configuring

+

+ Each question traces to a gotcha in `references/gotchas.md`.

+

+ | Question | Why it matters | What a good answer adds | What proper configuration adds over just doing it |

+ |---|---|---|---|

+ | "Which grants product is installed or licensed today: Outbound Funds, Grants Management, or Grantmaking?" | The products share no objects, and Grantmaking cannot be turned off once on (Gotcha 1) | A named platform path, confirmed from installed packages and Setup | No automation is built against objects the org does not have |

+ | "Who needs to create awards, who reviews reports, and do grantees use a portal?" | Access needs the licence, the feature, and Manage Funding Awards; portals use a separate permission set (Gotcha 2) | A permission set group per persona, including Experience Cloud users | Users see the objects on day one without hand-built permissions |

+ | "Which requirement status means what: the grantee's state, the review decision, or both?" | Requirements carry `Status` and `ApprovalStatus`, and Rejected is standard (Gotcha 3) | A field-meaning table and the standard values in use | Reports and automation read the same field for the same question |

+ | "Which payments wait for which reports, and who releases them?" | The requirement-to-disbursement link exists, but enforcement is your automation (Gotcha 5) | Requirement-to-tranche mapping and a release rule | A tranche cannot be marked Paid before its report is approved |

+ | "Do applications come through Individual Application or the Spring '26 Application Form model?" | Individual Application gets no future enhancements and needs an Application RecordType Config (Gotcha 7) | A chosen application model and its record type setup | New programmes start on the model that will keep improving |

+ | "How are amendments and multi-year terms recorded?" | One agreement is one award with master-detail tranches; changes go on amendments (Gotcha 8) | An amendment process and the award `Status` rule | Committed totals report once, not once per tranche |

+

+ What proper configuration adds over "just creating awards": one award per agreement with its tranches and requirements as children, statuses whose meaning is written down, and payment release tied to the reports that should gate it.

+

+ The Outbound Funds Module is a managed package, namespace `outfunds`, published as "a community developed and maintained Open Source Commons project." Its objects are `Funding_Program__c`, `Funding_Request__c`, `Funding_Request_Role__c`, `Disbursement__c`, `Requirement__c`, and `Review__c`. A grant is a Funding Request (with `Requested_Amount__c`, `Awarded_Amount__c`, `Status__c`, term dates, and rollups such as `Total_Disbursed__c`); disbursements and requirements are its children, and a requirement can look up the disbursement it relates to. An NPSP extension package (`outfundsnpspext`) links disbursements to NPSP General Accounting Units through `GAU_Expenditure__c`.

+ - Status fields are package picklists; transitions are not governed by the platform.

+ - Support comes from the Open Source Commons community, not a Salesforce product line.

+ - OFM is not compatible with Grantmaking objects: moving between them is a data transformation.

+ - (Corrected: the earlier text said OFM ties grants to the Opportunity through a lookup and has no requirement object; the package source shows neither an Opportunity field on `Funding_Request__c` nor a missing requirement object.)

+ ### Platform Path 2: Nonprofit Cloud for Grantmaking (Grantmaking)

+ Grantmaking is a platform feature available in Nonprofit Cloud for Grantmaking and Public Sector Solutions. Its standard objects include `FundingOpportunity`, `FundingAward`, `FundingAwardAmendment`, `FundingDisbursement`, `FundingAwardRequirement`, `FundingAwardRqmtSection`, `Budget` and related budget objects, and the application objects. The three objects most grant setups touch:

+ | Object | Key fields | Notes |

+ |---|---|---|

+ | `FundingAward` | `Amount` (total award), `AwardeeId` (business or person account), `ContactId`, `FundingOpportunityId`, `IndividualApplicationId` or `ApplicationFormId`, `StartDate`, `EndDate`, `Status` (Active, Cancelled, Completed) | One record per grant agreement |

+ | `FundingDisbursement` | `FundingAwardId` (master-detail), `Amount`, `ScheduledDate`, `DisbursementDate`, `IsApproved`, `PaymentMethodType`, `Status` (Scheduled, Pending Approval, Approved, Processing, Paid, Returned, Cancelled) | A payment "made or scheduled to be made"; no Draft value |

+ | `FundingAwardRequirement` | `FundingAwardId` (master-detail), `FundingDisbursementId`, `Type` (Combined Report, Contract, Financial Report, Narrative Report), `DueDate`, `AssignedContactId`, `AssignedUserId`, `Status` (Open, In Progress, Submitted, Delayed, Approved, Rejected), `ApprovalStatus` (New, In Review, Approved, Rejected), `IsSubmitted`, `SubmittedDate` | A deliverable or milestone for an award or a disbursement |

+ These are standard objects without package prefixes, available only with the Grantmaking licence, Grantmaking turned on, and the Manage Funding Awards permission. UNVERIFIED (2026-10-03): the earlier statement that Grantmaking is "part of the Agentforce Nonprofit product line as of 2024" was not found in a fetched source.

+ ### Requirement Status Model

+ The earlier version of this skill described a fixed Open, Submitted, Approved lifecycle with no Rejected state; the NPC Guide documents six `Status` values and a separate `ApprovalStatus`. A workable convention: `Status` tracks where the deliverable is (Open, In Progress, Submitted, Delayed), and the reviewer's decision is recorded both in `ApprovalStatus` (In Review, Approved, Rejected) and by moving `Status` to Approved or Rejected. A rejected deliverable goes back to Open or In Progress for resubmission, with feedback in `Description`. Document whichever convention you choose.

+ OFM and Grantmaking share no common objects, no shared APIs, and no native migration path. An org moving from OFM to Grantmaking must:

+ 3. Transform `outfunds__Requirement__c` → `FundingAwardRequirement`, mapping `Status__c` and `Type__c` values to the standard picklists

+ ### Pattern: Multi-Tranche Disbursement Schedule in Grantmaking

+ **When to use:** The award pays in several scheduled tranches and the org uses Grantmaking.

+ 1. Create one `FundingAward` with `Amount` = the total award, `AwardeeId` = the grantee account, and `Status` = Active.

+ 2. Create one `FundingDisbursement` per tranche with `Amount`, a future `ScheduledDate`, and `Status` = Scheduled.

+ 3. Move each tranche through Pending Approval, Approved, Processing, and Paid, setting `DisbursementDate` when paid.

+ 4. Set `FundingAward.Status` to Completed when every tranche is Paid or Cancelled (a Flow can do this).

+ **Why not the alternative:** Do not model tranches as separate `FundingAward` records: this breaks parent-child reporting and duplicates requirements.

+ ### Pattern: Deliverable Tracking and Payment Gating With FundingAwardRequirement

+ **When to use:** Grantees must submit reports before later tranches are released.

+ 1. At award setup, create one `FundingAwardRequirement` per deliverable with `Type`, `DueDate`, `AssignedContactId` (grantee) or `AssignedUserId`, `Status` = Open, and `FundingDisbursementId` = the tranche it gates.

+ 2. When the grantee submits, set `IsSubmitted`, `SubmittedDate`, and `Status` = Submitted; notify the grants manager.

+ 3. The reviewer sets `ApprovalStatus` and `Status` to Approved or Rejected.

+ 4. Enforce the gate: validation rules for same-record rules, and a record-triggered flow on `FundingDisbursement` that blocks `Status` = Paid while any requirement pointing at it is not Approved (`references/examples.md`, Example 3).

+ **Why not the alternative:** Tasks or Chatter posts produce no structured data, cannot be reported in aggregate, and cannot gate automation.

+ | Org is on NPSP, no Grantmaking licence | Outbound Funds Module (plus `outfundsnpspext` for GAU accounting) | Purpose-built package with requests, disbursements, and requirements |

+ | Org has the Grantmaking licence | Grantmaking (`FundingAward`, `FundingDisbursement`, `FundingAwardRequirement`) | Standard objects, applications, budgets, amendments, Experience Cloud components |

+ | Org is on Nonprofit Cloud but Grantmaking is NOT licensed | Do not use Grantmaking objects; evaluate OFM or buy the licence | The objects are not accessible without the licence |

+ | Org has the Grants Management managed package | Do not turn on Grantmaking in that org without a plan | Salesforce recommends against running both; Grantmaking cannot be turned off |

+ | Org needs to migrate from OFM to Grantmaking | Full data transformation project | No native migration path |

+ | New nonprofit org evaluating Salesforce for grantmaking | Grantmaking on the Spring '26 Application Form model | No migration cost; the model receiving enhancements |

+ 1. **Identify the platform path**: Confirm installed namespaces (`npsp`, `outfunds`, Grants Management) and the Grantmaking licence; do not proceed until the path is unambiguous.

+ 2. **Assess grant requirements**: Document tranches, deliverables and the tranches they gate, grantee portal access, application model, and reporting needs. Match them to the decision table above.

+ 3. **Turn on and grant access**: For Grantmaking: Setup > Quick Find "Grantmaking" > Grantmaking Settings > turn on (irreversible); assign Grantmaking Manager (and Grantmaking for Experience Cloud for portal users) through permission set groups; configure the application model and, for Individual Application, the Application RecordType Config.

+ 4. **Configure the data model**: Page layouts, field sets, and record types for awards, disbursements, and requirements; write down the requirement status convention.

+ 5. **Build lifecycle automation**: Validation rules for same-record rules and a record-triggered flow for the disbursement gate (`references/examples.md`, Example 3); a flow to complete awards.

+ 6. **Validate end to end and document**: Create a test award with tranches and requirements, walk every status, confirm reports, then record the platform path, picklist conventions, and automation for future support and migrations.

+ - [ ] Platform path (OFM vs. Grantmaking vs. Grants Management) is confirmed in writing, not assumed

+ - [ ] Grantmaking licence, feature switch, and Manage Funding Awards permission are verified if Grantmaking objects are in use

+ - [ ] `FundingDisbursement` tranches are children of the correct `FundingAward` (not separate awards)

+ - [ ] Requirement status convention (`Status` and `ApprovalStatus`) is documented and automation follows it

+ - [ ] Gating requirements reference their tranche through `FundingDisbursementId`, and a Paid tranche cannot bypass them

+ - [ ] No OFM API names (`outfunds__`) appear in automation built for Grantmaking, and vice versa

+ The full list with sources is in `references/gotchas.md`. The ones that most often break a grants setup:

+ | Gotcha | Consequence |

+ |---|---|

+ | Three different grants products; Grantmaking cannot be turned off (Gotcha 1) | Enabling it in the wrong org is permanent and confuses users |

+ | Two requirement status fields, with Rejected standard (Gotcha 3) | The earlier "Open, Submitted, Approved only" model was wrong; reports disagree if fields are mixed |

+ | Disbursement statuses have no Draft (Gotcha 4) | Automation built on Draft never fires; use Scheduled |