本文へ移動
cccskills
無料GitHub で公開

fundraising-process-mapping

Use when designing nonprofit fundraising lifecycle stages, donor pipeline workflows, cultivation-to-stewardship cycles, or Salesforce Opportunity sales process configuration for NPSP or Nonprofit Cloud. Trigger keywords: fundraising lifecycle, donor pipeline, cultivation stage, solicitation workflow, major gift process, moves management, NPSP Opportunity stages, stewardship cycle, NPC fundraising stages. NOT for lapsed donor re-engagement or portfolio segmentation — use admin/donor-lifecycle-requirements. NOT for Engagement Plan setup — use admin/npsp-engagement-plans.

インストール方法を見る

含まれるファイル(7)

  • SKILL.md17.6 KB
  • references/examples.md6.6 KB
  • references/gotchas.md5.9 KB
  • references/llm-anti-patterns.md8.8 KB
  • references/well-architected.md5.8 KB
  • scripts/check_fundraising_process_mapping.py10.3 KB
  • templates/fundraising-process-mapping-template.md5.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Fundraising Process Mapping

This skill activates when a practitioner needs to design or document the fundraising lifecycle in Salesforce — mapping donor cultivation, solicitation, and stewardship phases to Opportunity stages and sales processes in either NPSP (legacy) or Nonprofit Cloud (NPC). It covers the NPSP four-process model, the NPC stage model divergence, Moves Management alignment, and the decision framework for stage design across fundraising program types. It does NOT cover how to configure Engagement Plans, process gift entries, integrate payment processors, or manage recurring donations.


Before Starting

Gather this context before working on anything in this domain:

  • Confirm the platform — Determine whether the org is on legacy NPSP (the managed package, now end-of-life for new installs as of December 2025) or Nonprofit Cloud (NPC, the next-generation native Salesforce offering). The stage configuration approach, available objects, and feature availability differ materially between the two. If the org was created after December 2025 and does not have the npsp namespace in Setup > Installed Packages, it is on NPC or a blank org, not NPSP.
  • Identify program types — NPSP ships four pre-configured Opportunity sales processes: Donation, Grant, In-Kind, and Major Gift. Each has a distinct stage picklist sequence. Confirm which program types the organization runs and whether all four are needed or only a subset.
  • Understand who owns each stage — Solicitation and stewardship stages often have different responsible roles (prospect researcher, gift officer, stewardship coordinator). Mapping stage ownership prevents ambiguity about when a record moves and who is accountable.
  • Establish the probability model — Salesforce displays a Probability % field on Opportunity that forecasts pipeline value. Nonprofits using pipeline reports depend on accurate probabilities per stage. Gather any existing probability targets before designing stages.

Core Concepts

NPSP Four Pre-Configured Sales Processes

NPSP ships four Opportunity sales processes, each mapped to a specific Opportunity Record Type. These processes define the stage picklist values available to gift officers:

  1. Donation — Used for annual fund, direct mail, and general unrestricted gifts. Typical stages include Prospecting, Cultivation, Solicitation, Closed Won (e.g., "Pledged"), and Closed Lost. Stage names and probabilities are editable but the record type and process association must be preserved when customizing.
  2. Grant — Used for institutional grants from foundations, government, or corporations. Stages reflect the grant calendar: Letter of Inquiry, Application, Under Review, Awarded, Closed Lost. A key behavioral difference is the Close Date aligns to the grant decision deadline, not a solicitation event.
  3. In-Kind — Used for non-cash donations (goods, services, property). Stages are simpler: In Discussions, Accepted, Received, Declined. Valuation documentation is often tracked via a custom field rather than through stage.
  4. Major Gift — Used for high-value individual donor solicitations managed through Moves Management. Stages typically follow the cultivation arc: Identification, Qualification, Cultivation, Solicitation, Verbal Commitment, Pledged (Closed Won), Stewardship. Probability values are set low in early stages and increase as the relationship develops.

The Opportunity.StageName field drives all stage-based automation, rollups, and pipeline reports. The values available to a user depend on the Sales Process associated with the Opportunity's Record Type.

NPSP vs Nonprofit Cloud (NPC) Stage Model

NPSP and NPC are not interchangeable. As of December 2025, Salesforce no longer offers NPSP as a pre-configured package for new production orgs. New nonprofit orgs will be provisioned with Nonprofit Cloud (NPC) or a standard Sales Cloud org.

Key differences for fundraising process mapping:

  • NPSP stores fundraising data on the standard Opportunity object, extended with the npsp__ namespace fields. Sales processes and Record Types are standard Salesforce components configured in Setup.
  • NPC introduces new objects in the Fundraising module (e.g., GiftTransaction, GiftEntry) alongside or instead of the NPSP Opportunity model. NPC does not use NPSP Engagement Plans — that feature does not exist in NPC in the same form.
  • Stage field names may differ between NPSP and NPC. A stage value called "Pledged" in NPSP may not exist in an NPC-native stage set; practitioners must document existing values before attempting any lift-and-shift migration.

Moves Management Alignment

Moves Management is the fundraising methodology that tracks discrete relationship-building interactions ("moves") between gift officers and major gift prospects. In Salesforce with NPSP, Moves Management is reflected through:

  • Opportunity stage progression on the Major Gift sales process — each stage corresponds to a phase of the relationship (Qualification, Cultivation, Solicitation).
  • Contact or Account Contact Roles linking the prospect to the Opportunity.
  • Activities (Tasks and Events) logged against the Opportunity or Contact to record each move.
  • NPSP Engagement Plans applied to drive consistent stewardship task sequences post-close.

Moves Management in Salesforce is a process design discipline, not a standalone feature. The quality of the lifecycle map directly determines the usefulness of pipeline reports and gift officer dashboards.

Cultivation, Solicitation, and Stewardship Phases

Every major fundraising lifecycle — regardless of platform — moves through three broad phases:

  1. Cultivation — Building the relationship and assessing capacity and interest before making an ask. Salesforce stages in this phase typically have low probability values (5%–25%). Moves in this phase include discovery calls, site visits, impact presentations, and event invitations.
  2. Solicitation — Making the formal ask. A single stage (often called "Solicitation" or "Ask Made") with a probability that reflects confidence in the outcome (typically 50%–75% for major gifts). The Close Date should reflect the expected decision date.
  3. Stewardship — Post-close recognition, reporting, and relationship maintenance for future giving. NPSP does not ship a post-close stage by default (Closed Won ends the active pipeline), but some organizations add a "Stewardship" stage for in-progress gift agreements or multi-year pledges still under active management.

Common Patterns

Four-Process Stage Map (NPSP Standard)

When to use: The org is on legacy NPSP, runs multiple fundraising program types, and needs a documented stage map before any configuration or pipeline reporting is built.

How it works:

  1. List all four NPSP Record Types: Donation, Grant, In-Kind, Major Gift.
  2. For each Record Type, retrieve the associated Sales Process and list its current stage values with probabilities.
  3. For each stage, document: stage name, probability %, entry criteria (what event or decision moves the record into this stage), exit criteria (what triggers the move to the next stage), and responsible role.
  4. Flag any stages that are missing entry/exit criteria — these are pipeline report accuracy risks.
  5. Present the map to development leadership for sign-off before any Salesforce configuration work begins.

Why not the alternative: Skipping the documentation step and configuring stages directly in Setup leads to stage names that only one gift officer understands, missing probability values, and pipeline reports no one trusts.

NPC Stage Audit Before Customization

When to use: The org is on Nonprofit Cloud (NPC) or is migrating from NPSP to NPC and needs to map existing NPSP stages to their NPC equivalents before going live.

How it works:

  1. Export the current NPSP Opportunity stage picklist values and their Record Type assignments using the Salesforce Metadata API or Setup UI.
  2. Document all active Opportunity records by stage and Record Type to identify which stages have live data.
  3. Review the NPC fundraising object model and confirm which objects replace NPSP Opportunities for each program type.
  4. Build a mapping table: NPSP stage → NPC stage equivalent (or "no equivalent — requires new design").
  5. Identify automation, rollups, and reports that reference specific stage values by name — these must be updated as part of any NPC migration.

Why not the alternative: Assuming NPSP stage names carry over to NPC without validation leads to broken reports, failed automation, and lost historical data.


Decision Guidance

SituationRecommended ApproachReason
Org is on legacy NPSP, needs stage reviewUse the four-process NPSP standard stage map patternNPSP ships with these four processes; customization should be minimal and documented
New org created after December 2025Confirm NPC or standard Salesforce; do not assume NPSP is presentNPSP is no longer provisioned for new orgs as of Dec 2025
Migrating from NPSP to NPCRun the NPC stage audit before configurationStage names, objects, and features differ materially; direct lift-and-shift fails
Major gift program needs Moves Management trackingMap stages to Major Gift sales process with explicit entry/exit criteria and Activities loggingMoves Management is a process discipline expressed through stages and activities
Org runs only one fundraising program typeSingle sales process with a custom stage sequenceFour-process model adds unnecessary complexity for single-program orgs
Grant program stages need calendar alignmentClose Date = grant decision deadline; stage = current application statusGrant lifecycle is calendar-driven, not relationship-driven
Need stewardship tracking post-closeAdd a post-close stage or use Engagement Plans for stewardship tasksClosed Won ends pipeline visibility; multi-year pledges may need a stewardship stage

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

  1. Confirm platform and installed packages — Check Setup > Installed Packages for the npsp namespace. If absent and the org was created after December 2025, the org is NPC or standard Salesforce. Document the platform before any stage design work begins.
  2. Inventory existing Record Types and Sales Processes — In Setup > Opportunity Record Types and Setup > Sales Processes, list all existing configurations. For NPSP orgs, confirm the four standard processes are present (Donation, Grant, In-Kind, Major Gift). For NPC orgs, confirm which objects and stage fields are in use.
  3. Map the fundraising lifecycle per program type — For each active program type, produce a stage map with: stage name, probability %, entry criteria, exit criteria, and responsible role. Use the output template from this skill as the starting structure.
  4. Validate with development leadership — Present the stage map to the chief development officer or equivalent before any Salesforce configuration. Stage names must reflect how gift officers actually talk about their pipeline, not generic Salesforce defaults.
  5. Document Moves Management alignment for major gifts — For the Major Gift process, explicitly connect each stage to a phase of the Moves Management methodology (Identification, Qualification, Cultivation, Solicitation, Stewardship). This alignment drives gift officer dashboard design and pipeline forecasting.
  6. Identify automation dependencies — List any Flows, Process Builder processes, or Apex triggers that fire on stage changes. These must be reviewed and updated if stage values are modified.
  7. Hand off to implementation — Provide the completed stage map and automation dependency list to the configuration team. This skill's output ends at documented design; implementation of Engagement Plans, stage-change Flows, or rollup rules is handled by downstream skills.

Review Checklist

Run through these before marking work in this area complete:

  • Platform confirmed as NPSP or NPC (not assumed)
  • All active Opportunity Record Types and Sales Processes inventoried
  • Stage map produced for each active fundraising program type
  • Each stage has documented probability %, entry criteria, and exit criteria
  • Responsible role assigned to each stage
  • Major Gift stages aligned to Moves Management phases (Identification → Qualification → Cultivation → Solicitation → Stewardship)
  • Development leadership has reviewed and approved the stage map
  • Automation dependencies on stage values identified and listed for the implementation team
  • NPC/NPSP divergence flagged if org is post-December 2025 or migrating

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

  1. NPSP No Longer Available for New Orgs (December 2025) — Salesforce ended new NPSP provisioning in December 2025. Any engagement with a nonprofit org created after that date must confirm the actual platform before applying NPSP guidance. Recommending NPSP configuration steps in an NPC org will produce errors, confusion, or wasted setup work.
  2. NPC Does Not Have NPSP Engagement Plans — The Engagement Plans feature (npsp__Engagement_Plan_Template__c and related objects) is specific to the NPSP managed package. It does not exist in Nonprofit Cloud (NPC). Practitioners designing stewardship cadences for NPC orgs must use Flow, Cadences (Sales Engagement), or other native automation — not Engagement Plans.
  3. Sales Process Stage Values Are Picklist-Restricted — Changing a stage value name after Opportunities are in production does not update the existing records. Active pipeline records retain the old stage name, which may break reports and automation that reference the value by name. Stage renaming requires a data update job, not just a picklist edit.

Output Artifacts

ArtifactDescription
Fundraising stage mapPer-program-type table of stage name, probability, entry criteria, exit criteria, and responsible role
NPSP/NPC platform confirmation noteDocumented confirmation of which platform the org is on and what that means for stage configuration
Moves Management alignment matrixMapping of Major Gift stages to Moves Management phases (Identification, Qualification, Cultivation, Solicitation, Stewardship)
Automation dependency listList of Flows, triggers, or rollups that reference specific stage values and will need updating if stages change

Related Skills

  • npsp-engagement-plans — Use after stage design is complete to implement stewardship task automation on NPSP Opportunity Closed Won; Engagement Plans are an implementation tool, not a design tool
  • gift-entry-and-processing — Use for NPSP and NPC gift entry mechanics, batch processing, and payment processing flows; separate from lifecycle stage design
  • fundraising-integration-patterns — Use when the donor pipeline needs to connect to external CRMs, wealth screening tools, or peer-to-peer fundraising platforms
  • nonprofit-platform-architecture — Use for overall NPSP vs NPC platform selection and data architecture decisions

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Use this skill when writing test-first, behavior-driven acceptance criteria in Given/When/Then format for a Salesforce user story. Covers happy path, edge cases, negative paths, permission boundaries, and data-state preconditions so the AC block can drive UAT scripts and Apex test design downstream. Trigger keywords: given when then, gherkin, behavior driven AC, test first acceptance criteria, scenario outline, BDD acceptance criteria. NOT for the user-story format itself (use admin/user-story-writing-for-salesforce). NOT for UAT script writing (use admin/uat-test-case-design). NOT for Apex test method generation (use agents/test-class-generator). NOT for high-level UAT planning (use admin/uat-and-acceptance-criteria). More triggers: acceptance criteria record, ac_id, req_id on a criterion, artefact under test, negative case for a rule-type requirement, no-match fall-through criterion, oracle for a Then clause, test type apex flow manual, criteria linter, check_ac_format.py, --manifest-dir.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Task and Event objects: polymorphic WhatId/WhoId, Activity object model, ActivityHistory vs OpenActivity, activity timeline customization, bulk task creation, Einstein Activity Capture boundaries. NOT for turning on EAC or calendar sync — use admin/einstein-activity-capture-setup. NOT for Email-to-Case — use admin/case-management-setup. Covers ActivitiesSettings metadata, enableActivities, shared Task/Event custom fields and FLS, TaskStatus value sets, Shared Activities and TaskRelation/EventRelation, recurring and child activities, and partial-success bulk DML on Task.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Design Invocable Apex actions that return deterministic, agent-friendly errors instead of surfacing raw exceptions to the LLM. NOT for authoring the action itself — @InvocableMethod schema, labels, security context — use agentforce/custom-agent-actions-apex. NOT for the Apex tests that force each error branch — use agentforce/agent-action-unit-tests.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Use when designing how an Agentforce agent extracts structured input parameters (slots) from a user's natural-language utterance to invoke an action. Triggers: 'agent extract date from user', 'agent action argument extraction', 'agentforce slot filling', 'agent invocable input mapping', 'agent fails to fill required parameter'. NOT for action authoring (use agentforce/agent-actions) or for prompt-template variable binding (use agentforce/prompt-builder-templates).

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Apex test patterns for @InvocableMethod agent actions: per-reason-code branch coverage, bulk safety, callout mocking, deterministic assertions. NOT for testing whether the agent routes to the right topic or answers well — use agentforce/agent-testing-and-evaluation. NOT for designing the error envelope the tests assert on — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

Designing or reviewing Agentforce actions: Flow actions, Apex invocable actions, prompt-template actions, action naming, input and output contracts, confirmation requirements, and safe error behavior. Triggers: 'agent actions', 'build an agent that can look up an order', 'make the agent able to check order status', 'give the agent a capability', 'agent that can retrieve a record', 'flow action for agent', 'agent invocable action', 'action schema design'. NOT for writing the Apex class itself — use agentforce/custom-agent-actions-apex. NOT for the reason_code error envelope that stops an agent retry loop — use agentforce/agent-action-error-handling.

日本語の概要は準備中です。原文の説明を表示しています。

PranavNagrecha/AwesomeSalesforceSkills192026年10月4日 更新

PranavNagrecha のスキルをすべて見る

このスキルの問題を報告する