Grantmaking on Salesforce: From Application to Disbursement

Foundations and funders run one of the most process-heavy operations in the nonprofit sector, and a surprising number still run it on email, shared drives, and a spreadsheet that one person understands. Salesforce Grantmaking gives you standard objects for the whole lifecycle, from the pool of money through applications and review to awards, payments, and the reports you require back. This guide covers how to implement it, and the decisions that make the difference.

Grantmaking and grantseeking are different problems

Get this straight before you scope anything, because the words are used loosely and it causes real confusion in requirements workshops.

• Grantmaking is giving money away. You publish opportunities, receive applications, review them, make awards, pay out, and require reports back. This is what the Grantmaking objects are built for.
• Grantseeking is receiving money. You track prospective funders, deadlines, submissions, and the reports you owe. This is closer to fundraising, and most organizations model it with Opportunities and commitments plus a deadline and deliverable tracker.

Some organizations do both: an intermediary that receives a large government grant and re-grants it to community partners. If that is you, you need both models, and you need to be careful that a single record does not try to be an incoming grant and an outgoing grant at the same time.

This guide is about grantmaking. If you receive grants and need to report on what you achieved with them, the relevant work is in program and outcome management.

The grantmaking objects

These are core platform objects, shared with Public Sector Solutions, which is why some labels read as governmental.

Note the key relationships, because they define your reporting. FundingAward looks up to FundingOpportunity, to IndividualApplication, and to Budget. FundingDisbursement has a master-detail relationship to FundingAward, which means disbursements are owned by the award and roll up naturally. That master-detail is good news: paid to date against awarded is straightforward to report.

The lifecycle, object by object

1. Define the money. A FundingOpportunity for each pool: a program area, a funding round, a specific initiative. This is what constrains total awards and gives you your committed against available figure.
2. Receive applications. Each submission is an IndividualApplication linked to the opportunity, with the applicant as a Person Account or a business Account. Requested budgets attach through Budget.
3. Manage the work. IndividualApplicationTask tracks the checks: eligibility confirmation, due diligence, financial review, site visit.
4. Decide. Approved applications produce a FundingAward carrying the amount, term, and conditions.
5. Set conditions. FundingAwardRequirement records the deliverables and milestones: interim report due, final report due, evidence of match funding.
6. Pay. FundingDisbursement records each scheduled and actual payment, with scheduled date, disbursement date, amount, payment method, and approval status.
7. Close the loop. Requirements get satisfied, or they do not, and that history informs the next application from the same grantee.

The applicant experience

This is where grantmaking implementations most often disappoint, because the internal process gets all the design attention and the applicant gets a PDF form.

Decisions to make deliberately:

How do applications arrive?

• An Experience Cloud site gives applicants a login, the ability to save a draft, upload documents, and come back to submit reports later. This is the right answer for a funder with recurring grantees, and it costs licences.
• A public unauthenticated form is cheaper and fine for a single-round open call, but the applicant cannot save progress or return.
• An external form tool pushing into Salesforce works, but you own an integration and the applicant cannot see status.

Pick based on whether applicants come back. A community foundation with 200 repeat grantees who submit reports twice a year needs a portal. A one-off open call does not.

Two stage or one?

A letter of inquiry followed by a full application by invitation reduces work for everyone, especially the applicants you were never going to fund. If you do this, decide whether the letter of inquiry is its own IndividualApplication record that progresses, or a separate record that spawns a full application. Progressing one record keeps history in one place and is usually simpler.

Give applicants their status

The single most appreciated feature in any grants portal is an honest status and a realistic decision date. It also removes a large volume of email from your program officers.

Review, scoring, and conflicts of interest

Reviewers need to score applications consistently, and you need to prove the process was fair.

• Publish the criteria and weights before review opens. Store the score per criterion, not one overall number, so you can explain a decision and analyse reviewer patterns later.
• Manage conflicts of interest explicitly. A reviewer who sits on an applicant board must not see or score that application. This is an access control requirement, not a policy note, and IndividualApplnParticipant is how you grant or withhold that access.
• Expect reviewer disagreement and decide the rule now. Average the scores, take a third reviewer, or escalate to a committee. Whatever you choose, encode it so the outcome is not down to who shouts loudest in the meeting.
• Record the decision reason, including for declines. Applicants ask, and reusing the reason next round makes your feedback consistent.
• Keep the audit trail. Who scored what, when, and who made the final decision. Boards and auditors ask, sometimes years later.

Budgets that mean something

Budget tracks estimated revenue or expenses for a period, with BudgetCategory for line items. Funders use it in two directions, and mixing them causes confusion.

• The applicant's requested budget: what the grantee says they will spend the money on, by category.
• Your own grant budget: what your foundation has allocated to a program area, against which awards are committed.

Both are legitimate. Use record types or a clear type field so a report never mixes an applicant request with your internal allocation. This is a small design decision that prevents a category of embarrassing report.

If you require grantees to report actual spend against budget categories, decide the tolerance for variance and what happens when it is exceeded. Most funders allow reallocation up to a percentage without approval. Encode that threshold rather than handling every case by email.

Awards, disbursements, and requirements

Because FundingDisbursement is master-detail to FundingAward, the money reporting is clean. The design work is in the schedule and the conditions.

Payment schedules

Create the full disbursement schedule at award time, with scheduled dates and amounts, even though nothing has been paid. That gives you a cash flow forecast, which is the report your finance director actually wants and which spreadsheets do badly.

Then keep scheduled and actual separate. ScheduledDate and DisbursementDate exist for this reason. Overwriting the schedule with reality destroys your ability to see that payments habitually run three weeks late.

Conditional payments

Many grants pay in tranches contingent on a report. Model that as a FundingAwardRequirement linked to the disbursement it gates, and build the check so a payment cannot be approved while a required report is outstanding. This is exactly the kind of control that quietly fails when the process lives in email.

Requirement tracking

• Create requirements at award time with real due dates, not "annually".
• Remind grantees before the deadline, not after. This is a small automation with a large effect on your compliance rate.
• Track received, reviewed, and accepted as separate states. A report received is not a report accepted.
• Report on overdue requirements by program officer, because that is who can act on it.

Who can see which application

Grantmaking has a genuine access problem, and the participant objects exist to solve it without custom sharing machinery.

• IndividualApplnParticipant grants users or groups access to a specific application. Use it for assigned reviewers and program officers.
• FundingAwardParticipant does the same for awards, which matters because awards carry payment information.
• BudgetParticipant covers budgets, which often contain grantee financial detail they would not want shared.

Set the organization-wide default on these objects to Private and grant access through participants. Do not try to express "reviewer assigned to this application" through the role hierarchy, because reviewer assignment is per record and changes every round. This is the same principle we apply to the wider nonprofit sharing problem in the sharing model guide.

One more consideration: applicant financial statements and, for some funders, information about vulnerable beneficiaries sit inside applications. Treat that as confidential grantee data, and make sure a broad report or list view cannot expose it.

Closing the loop on grantee reporting

The reports funders most often cannot produce, and should:

1. Committed against available, per funding opportunity. Prevents over-awarding a pool.
2. Cash flow forecast from scheduled disbursements, by month.
3. Paid against awarded, per award, showing what remains.
4. Overdue requirements, by grantee and by program officer.
5. Time from submission to decision, which is the number applicants judge you on and the one most funders never measure.
6. Award distribution by geography, population served, or organization size, which is how a board evaluates whether the strategy is being executed.
7. Grantee history: everything one organization has applied for, received, and reported, on one screen before a renewal conversation.

The last one is the strongest argument for doing this in Salesforce at all. A program officer walking into a renewal meeting with the full history in front of them behaves differently from one working off a folder.

Common mistakes

• Overwriting scheduled payment dates with actual ones. You lose the ability to see systemic lateness.
• Creating awards without requirements. The conditions then live in a signed PDF nobody reads until an audit.
• Using the role hierarchy for reviewer access. Assignment is per record and per round. Use the participant objects.
• Mixing applicant budgets with internal allocations. Separate them with record types from the start.
• Building the internal process and leaving applicants a PDF. Applicant experience affects who applies, which affects your whole portfolio.
• Vague requirement due dates. "Annually" cannot be reported on or reminded about.

Frequently asked questions