6 Salesforce NPSP fields fundraising teams customize beyond default setup

Fundraising teams often reach a point where the default NPSP setup records the gift correctly but doesn’t capture enough of the decision-making around the ask. The Opportunity can show the donor, amount, stage, close date, campaign, payments, and related records. That still leaves practical questions unanswered: What amount did the gift officer ask for? When did the ask happen? What should the next ask be? How was the solicitation made? What giving vehicle did the donor use?

The answer isn’t to add fields every time someone wants another report column. Good Salesforce NPSP custom fields should represent information that has a stable meaning, a clear owner, and a reason to exist in reporting or daily work. They should also avoid copying data that NPSP already stores through Opportunities, Payments, General Accounting Units, Opportunity Contact Roles, recurring donations, or donor rollups.

This guide covers 6 fields that can fill those gaps for an established fundraising operation. It also explains where each field belongs, how it differs from existing NPSP fundraising fields, what reporting it can support, and what an admin should check before putting the field into production.

TL;DR

The 6 Salesforce NPSP custom fields covered in this guide are Suggested Next Ask, Ask Amount, Ask Date, Fundraising Relationship Stage, Solicitation Channel, and Gift Vehicle. Suggested Next Ask usually belongs on the Contact because it reflects the fundraiser’s current view of the donor or prospect. The other fields often belong on Opportunity because they describe a specific solicitation or gift. Before creating any custom field, check whether NPSP already stores the same information through Opportunities, Payments, GAU Allocations, Opportunity Contact Roles, recurring donations, or donor rollups.

• Suggested Next Ask: Records the amount a fundraiser plans to request during the next suitable solicitation.
• Ask Amount: Preserves the amount that was actually requested from the donor.
• Ask Date: Records when the formal solicitation took place.
• Fundraising Relationship Stage: Shows where the donor or prospect currently sits in the fundraising relationship.
• Solicitation Channel: Records how a specific ask was made, such as by phone, email, meeting, or direct mail.
• Gift Vehicle: Records the giving structure used for a contribution, such as a donor-advised fund or qualified charitable distribution.

What NPSP already gives fundraising teams

NPSP already covers much more than basic donor and gift storage, so custom field design should start with the packaged data model. Salesforce states that NPSP remains supported even though it is now at “End of Innovation” and no longer receives direct feature development. Current Salesforce Power of Us guidance also says existing NPSP organizations aren’t required to migrate to Agentforce Nonprofit until they are ready, which makes this guide directly relevant to teams maintaining established NPSP environments.

For fundraising, NPSP uses the standard Opportunity object to track revenue and includes record types for donations, grants, major gifts, in-kind gifts, matching gifts, and memberships. Salesforce’s NPSP fundraising data guidance explains that each record type can use its own process and fields, so a major gift doesn’t have to follow the same path as a simple annual fund donation. That existing structure is the base layer for Salesforce NPSP custom fields, not something the admin should work around.

The wider model matters as well. Contacts hold people, Accounts hold households or organizations, Opportunities hold revenue, Campaigns record outreach, Payments track money movement, and NPSP adds nonprofit-specific records around those standard objects. The official NPSP data model overview is worth reviewing before any schema change because many requests that sound like new fields belong on an existing related record instead. A clean NPSP donor management setup keeps each fact on the object that actually owns it.

When a custom field is worth adding

A useful custom field answers a question that staff repeatedly need and can’t answer from existing records without manual interpretation. That sounds simple, but field sprawl usually starts when a team confuses “we want to see this” with “we need to store this.” Salesforce has long advised nonprofit admins to use custom Contact fields for information with a stable meaning and to avoid duplicating values that can already be derived from giving history. Its article on categorizing nonprofit contacts in Salesforce makes the same point: a new field isn’t always the right answer when a rollup or report can provide the information.

Before adding Salesforce NPSP custom fields, write down the business question, object, data type, allowed values, entry owner, update rule, and reporting use. If the team can’t agree on those items, the field isn’t ready. A picklist with unclear values can become harder to fix than a missing field because historical records may carry several meanings for the same option.

Field 1: Suggested Next Ask

Suggested Next Ask gives a fundraiser a working amount for the next meaningful solicitation. It belongs on the Contact in many NPSP donor management models because it describes the current fundraising view of that person rather than 1 specific gift. A Currency field is usually the simplest choice. The label should make clear that the value is a recommendation or planning figure, not a promise from the donor.

Salesforce itself uses Suggested Next Ask as an example in its moves-management training, alongside prospect research values such as propensity to give and estimated charitable giving. The Salesforce prospect identification example shows why this is 1 of the more defensible Salesforce NPSP custom fields: it turns several pieces of fundraising judgment into 1 value a gift officer can use when preparing for a conversation. The field can be entered by staff or populated from a defined formula, but the method should be documented.

The safest starting point is to base the recommendation on information the organization already trusts. NPSP already has donor history available through rollups, so Suggested Next Ask doesn’t need to repeat lifetime giving. Salesforce’s Customizable Rollups overview documents built-in measures such as Total Gifts, Average Gift Amount, Total Number of Gifts, Largest Gift Amount, First Gift Date, and Last Gift Date. Those values can inform the recommendation while remaining separate from the final suggested amount. This keeps Salesforce NPSP custom fields focused on decisions rather than copied totals.

Recommended setup

Use a Currency field on Contact and decide who may edit it. Major gift teams may let portfolio owners update it after qualification or stewardship activity. Smaller teams may update it during a regular prospect review. If a formula creates the value, add a second process for exceptions because a donor’s recent conversation can matter more than past gift math.

The field becomes valuable when it feeds a report, list view, or portfolio review. A list of qualified prospects with Suggested Next Ask lets the team estimate near-term solicitation volume without changing Opportunity Amount before an ask is ready. That keeps Salesforce NPSP fundraising records closer to what has actually happened.

Field 2: Ask Amount

Ask Amount records the amount the fundraiser requested from the donor. That sounds close to Opportunity Amount, but the 2 values can describe different moments. Opportunity Amount may end up representing the expected commitment or the final gift. If a fundraiser asks for $25,000 and the donor agrees to $15,000, overwriting the original amount removes useful information about the solicitation.

A separate Ask Amount field preserves that history. This is 1 of the NPSP Opportunity fields that can support real analysis because it lets the team compare the request with the result. The Opportunity might show Ask Amount of $25,000 and final Amount of $15,000. A report can then group outcomes by gift officer, donor segment, campaign, or relationship stage without forcing staff to reconstruct the ask from notes. That’s a practical use of NPSP Opportunity fields.

The field should be a Currency type and should usually remain blank until a clear ask is made. Don’t populate it with Suggested Next Ask by default unless the organization has a specific process for doing so. A planning recommendation and an actual solicitation are different facts. Keeping them separate also makes NPSP donor management cleaner when the gift officer changes the ask during cultivation.

Ask Amount can also help distinguish qualification work from an active solicitation. Salesforce’s moves-management material explains that NPSP uses Opportunities to track the solicitation process, and its Path and Kanban guidance for fundraising shows how stages can represent progress toward an ask. Ask Amount adds the missing numeric record of what was requested once that point is reached.

Field 3: Ask Date

Ask Date records when the fundraiser made the solicitation. It shouldn’t be replaced by Opportunity Close Date because Close Date serves a different purpose in Salesforce. Close Date represents the expected or actual close of the Opportunity, and recurring donations can also use dates that follow their installment schedule. The day the request was presented may be earlier.

A Date field on Opportunity is usually enough. The team can populate it when the Opportunity enters a solicitation stage or when the gift officer confirms that the ask occurred. If automation fills the field, decide what happens when staff move the Opportunity backward or when an ask is postponed. Salesforce NPSP custom fields are easier to trust when their update rules cover those edge cases before launch.

Ask Date gives the team a simple way to study solicitation cycle time. A report can compare Ask Date with Close Date to show how long an Opportunity remained open after the request. It can also identify asks made during a campaign window, find solicitations with no result after a set period, or help managers review follow-up workload. Those uses are stronger than storing the date only because someone wants another activity field.

The field also helps when 1 Opportunity contains many activities. Calls, meetings, emails, and tasks can show the history of cultivation, but asking staff to infer the actual solicitation date from a long activity timeline creates extra work. Ask Date puts 1 specific fundraising event into a reportable field while the activity records continue to hold the detailed interaction history. It also makes Salesforce NPSP fundraising reports easier to interpret.

Field 4: Fundraising Relationship Stage

Fundraising Relationship Stage describes the current fundraising relationship with a constituent. It can use values such as Identification, Qualification, Cultivation, Solicitation, and Stewardship if those labels match the organization’s process. The purpose is to show where the person sits in the relationship cycle, not where a particular Opportunity sits in its sales process.

That difference matters because Opportunity Stage already exists. An Opportunity stage is tied to 1 revenue record, while a Contact-level relationship stage can continue across gifts and solicitations. A donor may have a Closed Won Opportunity from last year while currently being cultivated for a different major gift. Using 1 stage field for both ideas can blur NPSP donor management and make portfolio reports hard to read.

The field should generally live on Contact when the organization manages 1 main fundraising relationship per person. If the team needs separate relationship stages by program, portfolio, or funding interest, a single Contact picklist may be too simple. In that case, a related record or an Opportunity-based process may represent the work more accurately. The custom field should match the real cardinality of the process. That rule applies across NPSP fundraising fields.

Salesforce’s NPSP model already supports roles around a gift. Its Soft Credits overview explains that Opportunity Contact Roles can identify Donor, Influencer, Solicitor, and other relationships to an Opportunity. Fundraising Relationship Stage shouldn’t replace those roles. It answers the broader question of where the constituent currently sits in the fundraising relationship.

Field 5: Solicitation Channel

Solicitation Channel records how the ask was made. A short picklist might include Meeting, Phone, Email, Direct Mail, or Digital Form, but the final values should reflect the channels the organization actually reports on. This is 1 of the Salesforce NPSP custom fields where fewer controlled options usually produce better reporting than a large list built from every channel staff can imagine.

The field belongs on Opportunity because the same donor can receive different asks through different channels over time. It also shouldn’t replace Primary Campaign Source. A Campaign can tell you which appeal or outreach effort influenced the gift. Solicitation Channel tells you the method used for that specific request. Keeping those ideas separate makes Salesforce NPSP fundraising analysis more useful.

For example, an annual fund Campaign may include email outreach, phone calls, and individual meetings. Primary Campaign Source can remain the annual fund campaign across those Opportunities, while Solicitation Channel records how each ask happened. A report can then compare results within the same campaign without creating a campaign for every communication method.

Avoid putting communication consent into this field. Preferred communication details and consent rules belong elsewhere. NPSP already adds multiple contact fields and preferred phone or email handling, so admins should review Salesforce’s Contact management guidance before creating overlapping NPSP fundraising fields. Solicitation Channel should describe the ask that happened, not the donor’s general communication preference. This keeps NPSP Opportunity fields tied to 1 solicitation.

Field 6: Gift Vehicle

Gift Vehicle records the giving structure or intermediary through which the contribution was made. A consistent picklist might include Direct Gift, Donor-Advised Fund, Qualified Charitable Distribution, Private Foundation, or Charitable Trust. Keep asset types such as Stock and giving methods such as Payroll Giving in separate fields if the organization needs to report on them. This keeps the picklist focused on 1 classification: the giving structure behind the contribution.

This field is different from Payment Method. Payment Method can describe how money was received or processed, while Gift Vehicle can describe the legal or giving arrangement behind the gift. A donor-advised fund grant may arrive by check or electronic transfer, but the fundraising team may still need to know that the donor used a donor-advised fund for stewardship and attribution work. Keeping those concepts separate prevents an NPSP Opportunity fields design from mixing fundraising context with payment operations.

Gift Vehicle usually belongs on Opportunity because a donor can use more than 1 giving arrangement over time. If the organization wants to know a donor’s preferred vehicle, that could be a separate Contact-level value, but it should be created only if staff can keep it current. Having 1 historical donor-advised fund gift doesn’t automatically mean a donor-advised fund is the donor’s preferred future vehicle.

Fund designation is also a different concept. Salesforce documents General Accounting Units and Allocations as the NPSP feature for assigning all or part of a donation to a specific purpose. Its GAU Allocations guidance shows that a donation can be divided across multiple GAUs. Gift Vehicle shouldn’t become a substitute for that existing structure. Good Salesforce NPSP custom fields add context without replacing packaged records.

Fields you shouldn’t recreate

Several common field requests should trigger a review of existing NPSP features before an admin creates anything. A new Fund, Restriction, or Designation picklist may duplicate GAU Allocations. A new Solicitor text field may duplicate Opportunity Contact Roles. A new Lifetime Giving field may duplicate donor rollups. Duplicate fields can split history across several places and make reporting harder to trust.

Acknowledgment tracking is another example. NPSP already has Acknowledgment Status and Acknowledgment Date on Opportunity when the acknowledgment feature is configured. Salesforce’s donation acknowledgment setup explains how those fields work with donation acknowledgments. Creating another Thanked checkbox can produce 2 competing answers to the same question.

Preferred contact information also exists in NPSP. The package supports additional phone and email fields plus Preferred Phone and Preferred Email. A new “Best Email” text field might look harmless, but it can become stale when the Contact’s preferred value changes. Existing NPSP donor management fields should be used when they already represent the business meaning the fundraising team needs.

A useful rule is to search the object, related objects, installed NPSP fields, and available rollups before creating a new field. That review keeps NPSP fundraising fields from multiplying without a clear purpose. If the information already exists but is hard to see, change the page layout, Lightning record page, report, or Gift Entry template instead of copying the value into another location.

Where the 6 fields should live

Object choice determines whether a custom field stays accurate over time. Suggested Next Ask and Fundraising Relationship Stage usually belong on Contact because they describe the fundraiser’s current view of the person. Ask Amount, Ask Date, Solicitation Channel, and Gift Vehicle usually belong on Opportunity because each can change from 1 solicitation or gift to another. This split keeps Salesforce NPSP custom fields aligned with the record that owns the fact and gives NPSP Opportunity fields a clear boundary.

There are exceptions. Institutional fundraising may place some planning values on Account rather than Contact. A team using separate Opportunities for every qualified ask may decide that relationship stage is already represented by Opportunity Stage and doesn’t need another field. The right NPSP Opportunity fields design follows the team’s record model rather than forcing every organization into the same schema.

Field descriptions should also state the ownership rule. For example, Ask Date can say “Date the fundraiser made the formal solicitation” and Suggested Next Ask can say “Current recommended amount for the next solicitation, maintained by the portfolio owner.” Clear descriptions reduce the chance that staff use a field for a second purpose later.

How to configure the fields without breaking Gift Entry

Creating a field in Object Manager is only the first step. Users need permission to see it, the right page must display it, and the entry tool they use must accept it. A field can exist on Opportunity and still be absent from Gift Entry or a Lightning record page. Salesforce published a 2026 support article on custom fields that don’t appear in NPSP interfaces, which points admins toward field-level security, Gift Entry templates, Lightning page assignments, and field sets as common places to check.

Gift Entry deserves specific testing because its forms are configured through templates and Advanced Mapping rather than behaving like a plain Opportunity edit page. Salesforce’s Gift Entry template documentation explains that templates can include fields from Opportunity, Payment, GAU Allocation, and other mapped object groups. If an Opportunity custom field should be entered with a gift, add it where the actual users enter gifts instead of assuming the standard page layout is enough.

Advanced Mapping matters when custom values need to move through NPSP Data Importer or Gift Entry. Salesforce’s Advanced NPSP Mapping documentation states that custom fields outside the existing mappings require mapping work. That means the admin should test creation, editing, import, batch entry, reporting, and permissions before declaring the new Salesforce NPSP fundraising field finished. The same check should cover all Salesforce NPSP custom fields used in gift processing.

A small sandbox test set is useful. Create a new donor, an existing donor with past giving, a 1-time Opportunity, and a recurring gift scenario. Verify where each field is visible, who can edit it, what happens when it is blank, and whether reports return the expected value. This catches setup errors before staff start building history in the field.

How Recurring Donations change field design

Recurring donations introduce a second record layer. The Recurring Donation record stores the schedule and donor relationship, while installment Opportunities represent individual expected gifts. A field such as Solicitation Channel might describe the original recurring commitment, every installment, or both. The team has to decide that meaning before it creates the field.

NPSP can map custom fields from Recurring Donation to installment Opportunities when matching field types exist. Salesforce’s Recurring Donation custom field mapping instructions explain that the package copies mapped values into new installment Opportunities. This is useful when an Opportunity-level report needs the original Solicitation Channel or Gift Vehicle for every installment.

Don’t map every custom field automatically. Ask Amount and Ask Date may describe the original solicitation, but repeating those values on every installment can mislead a report that counts Opportunities as separate asks. In some NPSP donor management models, those values belong only on the original solicitation record or Recurring Donation. The reporting question should decide the mapping. This matters for Salesforce NPSP fundraising because recurring gifts can create many installment Opportunities.

Custom Recurring Donation fields also have a visibility detail. Adding a field to the normal page layout doesn’t automatically make it editable in the NPSP recurring donation entry form. Salesforce documents a separate field-set step for adding custom fields to that form. Admins should test the actual entry path before asking fundraisers to use a new value.

Reporting with the 6 custom fields

The 6 fields become useful when they answer recurring management questions. Suggested Next Ask can support a portfolio report showing the amount a team expects to request next. Ask Amount and final Opportunity Amount can show how actual gifts compare with requests. Ask Date can support aging reports. Solicitation Channel can show how different forms of asking perform within the same campaign. Gift Vehicle can help staff see how donors are choosing to give.

A simple major-gift report could include Contact, Opportunity, Fundraising Relationship Stage, Suggested Next Ask, Ask Amount, Ask Date, Opportunity Stage, Amount, and Close Date. That report combines donor-level planning fields with NPSP Opportunity fields without flattening them into 1 concept. Managers can see whether qualified prospects have a next ask, whether active solicitations have an ask amount and date, and whether stalled Opportunities need review. The report also puts NPSP Opportunity fields beside donor-level planning values without confusing the 2.

Reporting should also expose missing data. A field with 40% blank values may be a training problem, a workflow problem, or evidence that the field isn’t useful enough to keep. Add filters for open major-gift Opportunities where Ask Amount is blank after the solicitation stage, or Contacts in Solicitation where Suggested Next Ask is blank. Those reports make Salesforce NPSP custom fields part of normal operating discipline rather than passive database decoration.

Avoid treating correlation as proof. A higher average gift for in-person solicitations doesn’t prove the channel caused the result because major prospects may be more likely to receive meetings. Reports should support fundraising review and follow-up, while staff still apply context to the numbers.

Governance rules that keep custom fields useful

Field governance starts before creation. Give each field a plain definition, an owner, and a reason for keeping it. Record the object, field type, allowed values, update rule, and reports that depend on it. This makes later NPSP fundraising fields reviews easier and gives a future admin enough context to understand why each field exists. Clear ownership also keeps NPSP fundraising fields useful after staff changes.

Permissions should match the work. Prospect research values may be editable only by research staff or portfolio owners, while Gift Vehicle may be entered by gift processing staff. Ask Amount and Ask Date may belong to frontline fundraisers. NPSP donor management gets weaker when every user can change every planning value without a shared rule.

Review the fields on a schedule. Look for low completion rates, values that no report uses, stale picklist options, and fields that now duplicate another source. Retiring an unused field can make the remaining fields easier for staff to find and maintain.

Implementation checklist for fundraising teams

Start with the business process, then create the field, then test every place that uses it. Don’t create all 6 Salesforce NPSP custom fields in production and ask staff to decide how they work afterward.

Use this checklist before release:

·   Confirm the information doesn’t already exist in NPSP or a connected system.

·   Put the field on the object that owns the fact.

·   Define the field type, allowed values, and update owner.

·   Set field-level security and add the field to the right user interface.

·   Map it for imports or recurring donations only when needed.

·   Build at least 1 report that proves why the field exists.

·   Test blank values, edits, closed Opportunities, and recurring gifts before release.

Common design mistakes to avoid

The biggest mistake is storing the same fact twice. A custom Solicitor field can conflict with Opportunity Contact Roles, while a custom Fund field can conflict with GAU Allocations. When 2 fields answer the same question, reports can disagree.

Changing history also shouldn’t live on Contact when the value belongs to 1 solicitation. Ask Amount, Ask Date, Solicitation Channel, and Gift Vehicle can vary each time. Opportunity is usually the better home for that history.

Be careful with required fields as well. Gift Entry, imports, recurring donation automation, and older integrations may create records before a value is known. A conditional validation rule can require the field at the right stage without blocking valid record creation. Use controlled picklists when staff need consistent grouping in reports.

A practical way to extend NPSP without field sprawl

The best Salesforce NPSP custom fields fill a defined gap in the fundraising record and leave the rest of NPSP alone. Suggested Next Ask gives the fundraiser a current planning value. Ask Amount and Ask Date preserve the real solicitation. Fundraising Relationship Stage gives a donor-level view when Opportunity Stage isn’t enough. Solicitation Channel and Gift Vehicle add context that can support follow-up and reporting.

The main discipline is deciding what each field means before deciding where it appears. Existing Salesforce NPSP fundraising features should remain the source of truth for gifts, payments, fund allocations, soft credits, acknowledgments, campaigns, and donor totals. The 6 fields in this guide work best as a small extension to that model rather than a parallel fundraising database built inside custom fields.

A mature NPSP donor management model should also be willing to say no to a field request. If a report formula can answer the question, use the report. If a managed NPSP feature already stores the information, expose that feature. If the data changes many times and history matters, use a related record instead of 1 Contact field. Those choices keep NPSP fundraising fields understandable for the next admin and useful for the people raising money today.

FAQs

What are the most useful Salesforce NPSP custom fields for fundraising?

Suggested Next Ask, Ask Amount, Ask Date, Fundraising Relationship Stage, Solicitation Channel, and Gift Vehicle are strong candidates for established fundraising teams. They add planning and solicitation context without recreating core donation data that NPSP already stores.

Should Suggested Next Ask be on Contact or Opportunity?

Contact is usually the better home when Suggested Next Ask represents the fundraiser’s current recommendation for that person. If the amount belongs only to 1 active solicitation, the organization may instead keep it on the Opportunity.

Is Ask Amount the same as Opportunity Amount?

No. Ask Amount can preserve what the fundraiser requested, while Opportunity Amount can represent the expected or final value of the gift. Keeping both allows the team to compare the request with the outcome.

Why add Ask Date if Opportunity has Close Date?

Ask Date records when the formal solicitation occurred. Close Date records when the Opportunity is expected to close or did close. Those dates can differ by weeks or months in major-gift fundraising.

Should Fundraising Relationship Stage replace Opportunity Stage?

Usually no. Fundraising Relationship Stage can describe the donor’s wider relationship with the organization, while Opportunity Stage describes 1 specific solicitation or revenue record. Some teams may decide Opportunity Stage already covers their process.

What object should hold Solicitation Channel?

Opportunity is usually the right object because the same donor can be asked through different channels over time. Keeping the value on each Opportunity preserves solicitation history.

Is Gift Vehicle the same as Payment Method?

No. Gift Vehicle can describe the giving arrangement, such as a donor-advised fund or qualified charitable distribution. Payment Method describes how the payment itself was received or processed.

Should we create a custom Fund field in NPSP?

Usually not if the purpose is to designate all or part of a gift to a fund or program. NPSP already provides General Accounting Units and GAU Allocations for that purpose.

Should we create a custom Solicitor field?

Check Opportunity Contact Roles first. NPSP already supports roles such as Solicitor and can use those roles for soft-credit behavior where configured. A separate text field may duplicate that relationship.

Can NPSP rollups replace some custom fields?

Yes. NPSP already provides giving totals and dates, and Customizable Rollups can create additional summaries. A new stored field isn’t needed when the required value can be calculated reliably from existing gift history.

Do custom Opportunity fields automatically appear in Gift Entry?

No. Visibility depends on permissions, mapping, and the Gift Entry template or interface being used. Admins should test the exact entry path used by gift-processing staff before release.

Can custom fields flow from Recurring Donations to Opportunities?

Yes. NPSP supports custom field mapping between Recurring Donation records and installment Opportunities when compatible field types are configured. Teams should map only values that make sense on every new installment.

Should Salesforce NPSP custom fields be required?

Only when the organization can guarantee the value is available at the required point in every relevant record-creation path. Conditional validation is often safer than making a field universally required at the schema level.

How often should NPSP custom fields be reviewed?

Review them at least during regular admin or fundraising operations reviews and before large process changes. Look for unused fields, poor completion rates, duplicate meanings, stale picklist values, and reports that no longer use the field.

How many custom fundraising fields should an NPSP org have?

There isn’t a correct number. The goal is to keep fields that have distinct meanings and active uses. A smaller set with clear ownership is easier to maintain than a large set created for 1-time requests.