Salesforce-Nonprofit-Success-Pack-Consultant Practice Test Questions

Explanation:
The requirement is to categorize donors (Contacts) into recognition levels (Gold, Silver, Bronze) based on their year-to-date giving. This is a classic use case for donor recognition and stewardship. NPSP has a built-in, no-code feature specifically designed for this purpose: Levels. Levels automatically calculate a Contact's cumulative giving (with options for date ranges like "This Year") and assign a corresponding recognition level, which is then displayed on the Contact record.

Correct Option:

C. Set up NPSP Levels for the categories based on Total Gifts This Year.
NPSP Levels are a dedicated feature in Recurring Donations & Levels Settings.

You define Level names (Gold, Silver, Bronze) and the minimum amount for each (e.g., Gold = $1,000+).

You specify the source field for the calculation, such as "Total Gifts This Year" from the Contact's Soft Credit Rollups.

NPSP automatically evaluates each Contact's giving and assigns/updates their Level accordingly, with no custom automation needed.

Incorrect Option:

A. Create a picklist field that will display the categories based on the Total Gifts This Year field.
A simple picklist field is static; it cannot automatically calculate and update its value based on another field's changing total. It would require manual updating, defeating the purpose of automated donor recognition.

B. Create a custom field on the Opportunity that will display the categories and a process in Process Builder to populate the value based on the Total Gifts This Year field.
This is misplaced logic. Donor Levels are an attribute of the Contact (the donor), not of individual Opportunities (gifts). Building automation on the Opportunity to try to set a Contact-level category is unnecessarily complex and would require aggregating gifts, which is what the NPSP Levels feature already does efficiently.

D. Create a custom field on the Opportunity that will display the categories and a custom trigger to populate the value based on the Total Gifts This Year field.
Similar to Option B, this places the logic on the wrong object (Opportunity instead of Contact). More importantly, writing a custom trigger is unnecessary "re-inventing the wheel" when a robust, configurable, and supported standard NPSP feature (Levels) exists for this exact purpose.

Reference:
NPSP Documentation on Levels. This feature is explicitly described as a way to "recognize donors by creating donor levels" that are "automatically assigned to contacts based on their total giving within a specific date range," using fields like "Total Gifts Last Year" or "Total Gifts This Year."

Explanation:
This question focuses on troubleshooting Customizable Rollups (CRLP) in NPSP, a core feature for roll-up summary operations. A runtime error during record update typically points to a data validation or permission issue on the target record itself, not a configuration error in the rollup definition. The CRLP engine successfully calculates the value but fails when saving it.

Correct Option:

C. If the Target Field has a validation rule.
A validation rule on the target object can block the rollup's update even if the calculated value is correct. The CRLP process runs in the system context but must still obey all defined validation rules. This is the most common cause for "update failed" errors after calculation, as the rule's logic may conflict with the automated update's context or data state.

Incorrect Options:

A. If the Target Field exists.
This would cause a deployment or configuration error when setting up the rollup definition, not a runtime update error. The system validates the field's existence when the Customizable Rollup is created or saved, not during execution.

B. If the Target Field is an NPSP field.
Customizable Rollups can update both standard fields and custom fields (NPSP or otherwise). The field's origin does not cause a runtime update failure. The critical factors are field permissions, data type, and any constraints like validation rules.

D. If the Target Object is a custom object.
Customizable Rollups are designed to work with both standard and custom objects. The object type is not a source of runtime update errors. The error is specific to the record update, which depends on field-level and object-level permissions and validations, not the object's classification.

Reference:
Salesforce Help: "Customizable Rollups Troubleshooting" and "Considerations for Customizable Rollups" specifically mention validation rules as a common cause for update failures.

Explanation:
The Nonprofit Success Pack (NPSP) tracks Memberships as a specific type of Opportunity record, similar to how it tracks standard donations and grants. To effectively manage, report on, and automate the membership process (including features like membership start/end dates and status rollups), the recommended and required configuration step is to create a dedicated Opportunity Record Type for memberships. This ensures the correct fields, page layouts, and business processes are used for these revenue records.

Correct Option: A

A. Create a Membership Opportunity record type.
In NPSP, memberships are fundamentally tracked as Opportunity records because they represent a financial transaction or contribution to the nonprofit.

Creating a specific Membership Opportunity Record Type is a required configuration step to enable the full NPSP Membership features. This record type differentiates membership payments from general donations, grants, and other revenue.

The dedicated record type allows a consultant to assign a unique page layout that includes NPSP-specific membership fields (like Membership Start Date, End Date, and Member Level) and ensures proper rollups of membership status to the Contact and Account records.

Incorrect Option:

B. Add a value in the Type field on Opportunity for Membership.
While adding a "Membership" value to the standard Type picklist field on the Opportunity object could be done, it is not the official or best practice way to set up NPSP Memberships. The NPSP framework is designed to leverage Record Types for different revenue types (Donation, Grant, Membership, etc.) because Record Types control the entire business process, page layout, and available picklist values, which is much more comprehensive than a simple picklist value change.

C. Create a Membership Affiliation record type.
Affiliations in NPSP are used to track a formal relationship between a Contact and an Organization Account (e.g., an employee, a board member). They are essential for organizational relationships but have no direct role in tracking the financial transaction and expiration details of a membership itself. The membership transaction is managed on the Opportunity object, not the Affiliation object.

D. Add a checkbox field on the Opportunity called "Membership".
A simple checkbox field is insufficient for configuring the NPSP Membership feature. NPSP memberships require several specialized fields (Start Date, End Date, Member Level, Membership Status) and often different sales processes than a regular donation. The best way to manage these differences is through a dedicated Record Type, which controls the visibility of all required fields and the business process.

Reference:
Configure Memberships - Salesforce Help

Explanation:
In the NPSP Household Account model, every Contact is automatically linked to a Household Account that represents "where they live" (the family/household). Separately, the Primary Affiliation field (npe01__One2OneContact__c or Affiliation object) connects the Contact to an Organization Account that represents "where they work" or their primary organizational relationship (e.g., employer, school, volunteer organization). This clear separation enables accurate household mailing and organizational relationship tracking.

Correct Option:

B – A Contact's Account is where they live, a Contact's Primary Affiliation is where they work.
In the Household Account model, the Account record linked directly to the Contact (One-to-One or Household model) is always the Household Account – representing the residence.

Primary Affiliation (via the Affiliations object) creates a relationship to an Organization Account – typically the employer or main volunteer organization.

This design supports separate household communications and organizational reporting (e.g., corporate donors, board members).

Incorrect Option:

A – A Contact's Account is the same as the Contact record, a Contact's Primary Affiliation is the Contact's Household.
This describes the outdated One-to-One model, not the current Household Account model. In the Household model, the Account is a separate Household record, not the Contact itself.

C – A Contact's Account is where they work, a Contact's Primary Affiliation is where they live.
This is the reverse of NPSP standard behavior. NPSP uses the Household Account for residence and Primary Affiliation for organizational/employment relationships.

D – A Contact's Account is the same as a "bucket" where all Contacts are associated, a Contact's Primary Affiliation is the Contact's Household.
This describes the legacy Bucket Account model (Individual Account), which is no longer recommended. In the Household model, Contacts are not in a generic bucket; they belong to specific Household Accounts.

Reference:
Salesforce Nonprofit Success Pack (NPSP) Documentation → Account Models → Household Account Model

Explanation:
The question requires a two-part solution within NPSP:

Automated Scoring/Categorization based on client factors (age, income, health).

Automated Task Creation and Assignment for follow-up related to the client.

The combination of Levels and Engagement Plans directly addresses both of these requirements in a standard, reusable NPSP configuration. Levels automatically categorize the client (assign a "score" or Tier) based on custom criteria (e.g., using age, income, and health fields via a Flow), and Engagement Plans use these categories to trigger and assign a structured set of follow-up Tasks.

Correct Option: C

C. Engagement Plans and Levels
Levels: These are used to automatically assign a category or tier (e.g., "High-Need," "Standard-Need," "Low-Need") to Contact records based on their data. The nonprofit can define logic (via a Flow or NPSP's legacy Level creation tool) using the client's age, income, and number of health conditions to calculate the score and assign the correct Level.

Engagement Plans: These are templates that define a series of required Tasks with specific due dates and assignees. The consultant can set up automation (using a Flow) to apply a specific Engagement Plan template (e.g., "High-Need Case Management Plan") to the client's Contact or Case record when they are assigned a particular Level.

Incorrect Option:

A. Activities and Customizable Rollups
Activities (Tasks/Events) are the individual records used to track a follow-up, but they are created by an Engagement Plan or Flow—they are not the automation tool itself. Customizable Rollups are used to summarize data from child records (like the total number of donations or volunteer hours) up to the parent record; they cannot automatically assign a score or create a new series of tasks.

B. Volunteer Recurrence and Customizable Rollups
Volunteer Recurrence is a feature of the NPSP Volunteers for Salesforce package (or its successor) used specifically for scheduling repeating volunteer shifts. This has no function in client scoring or case management task automation. Customizable Rollups, as noted above, are for data aggregation, not task automation.

D. Volunteer Wizard and Reports
The Volunteer Wizard is part of the Volunteers for Salesforce package used for registering volunteers for shifts. This is completely unrelated to client scoring and case management tasks. Reports are for viewing data after it has been entered and automated; they cannot perform the automation (scoring or task creation) requested.

Explanation:
The Nonprofit Success Pack (NPSP) includes out-of-the-box functionality to automatically generate and send personalized donation acknowledgment emails immediately after an Opportunity (donation) is marked as closed-won. Using standard NPSP features such as Opportunity Roll-Up fields, customizable Email Templates, Process Builder/Flow triggers, or the free Elevate Donation Integration, nonprofits can achieve fully automated, branded thank-you emails at zero additional licensing cost.

Correct Option:

A – Nonprofit Success Pack
NPSP provides pre-built automation for acknowledgments via Email Alerts in Flows/Process Builder triggered on Opportunity stage change.

Supports merge fields for donor name, amount, date, campaign, and custom thank-you messages using standard or HTML email templates.

Works with the free Nonprofit Cloud Starter license bundle; no extra paid add-ons required for basic to advanced acknowledgment needs.

Incorrect Option:

B – Commerce Cloud
Commerce Cloud is an e-commerce platform for online stores and payment processing, not a cost-effective solution for simple donation acknowledgment emails.

It is expensive and overkill when the requirement is just sending thank-you emails.

C – Pardot
Pardot (now Marketing Cloud Account Engagement) is a B2B marketing automation tool requiring separate paid licenses.

While it can send emails, it is not designed for transactional donation acknowledgments and adds unnecessary cost/complexity.

D – Marketing Cloud
Marketing Cloud is an enterprise-level marketing platform with high licensing cost (thousands of dollars per month).

Suitable for large-scale, sophisticated donor journeys, but far too expensive and complex when the only need is automated thank-you emails after a donation.

Reference:
NPSP Documentation → Opportunities → “Automatically Send Acknowledgment Emails”

Explanation:
This question addresses tracking multi-year initiatives within NPSP's Campaign structure. Campaigns are the primary NPSP object for tracking programs, projects, and fundraising efforts over time. Using a Campaign hierarchy is the declarative, native Salesforce method to model parent-child relationships, perfectly suited for organizing annual goals (child Campaigns) under a multi-year project (parent Campaign).

Correct Option:

B. Create a Campaign hierarchy for project and year.
This approach creates a parent Campaign for each overall project and child Campaigns for each fiscal year. It leverages native Campaign Member and Opportunity association to track donations and progress per year. Roll-up reports and NPSP's Campaign Influence allow for clear tracking of goals and results at both the annual and overall project levels.

Incorrect Options:

A. Create a custom object for year and a custom object for project to track.
This is over-engineered and abandons the powerful, pre-built functionality of Campaigns in NPSP. It would require complex customizations, breaking standard reporting, Campaign Influence, and the native relationship between Opportunities and fundraising efforts.

C. Create reports with bucketing and filters.
While reports are necessary for analysis, they are a downstream output, not a data structure. Bucketing and filtering cannot enforce or maintain the relationship between projects and years at the data level. It's a reporting workaround for a poor data model.

D. Create a process that populates custom fields for each year and project on Opportunities.
This creates a brittle, hard-coded solution. Adding a new year would require schema changes (new fields). It also fails to leverage the relational power of Salesforce, making reporting and roll-ups across projects or years cumbersome compared to a hierarchical model.

Reference:
NPSP Documentation: "Campaigns" and "How to Use Campaigns for Fundraising." The use of Campaign hierarchies is a recommended best practice for structuring multi-year programs and tracking their associated Opportunities and goals.

Explanation:
When importing new gifts (Opportunities) in the Nonprofit Success Pack (NPSP), the system needs to know which Contact should automatically receive "Hard Credit" for the donation. Hard credit is the legal acknowledgment that a specific person made the gift. NPSP manages this through a setting that defines the default Contact Role (e.g., 'Donor', 'Household Member') that should be automatically assigned hard credit on every new Opportunity. This critical, organization-wide configuration is controlled within the central administration area for the entire package.

Correct Option: C

C. NPSP Settings
The NPSP Settings tab is the central hub for configuring system-wide defaults and critical automation settings for the Nonprofit Success Pack.

Specifically, the default Opportunity Contact Role for Hard Credit is configured under NPSP Settings > Donations > Contact Roles.

This setting ensures that when a new donation is created (manually or via import), the primary Contact linked to the Opportunity is automatically assigned the correct role (usually 'Donor') and is designated as the Hard Credit recipient.

Incorrect Option:

A. Opportunity Settings
Opportunity Settings (or "Setup > Object Manager > Opportunity") manage standard Salesforce features like fields, validation rules, and record types. While relevant to Opportunities, they do not control the NPSP-specific business logic for assigning default Hard Credit Contact Roles. This particular functionality is unique to NPSP.

B. Affiliation record
An Affiliation record tracks the relationship between a Contact and an Organization Account (e.g., "Board Member" at XYZ Company). This record determines organizational relationships and rollups but has no role in defining the automatic Hard Credit Contact Role for individual donation records.

D. Relationship record
A Relationship record tracks the connection between two Contact records (e.g., "Parent of," "Spouse"). This is crucial for Soft Credit assignment and household mapping, but it is not where the system-wide default role for Hard Credit (the legal donor) on an Opportunity is configured.

Reference:
Configure Contact Roles - Salesforce Help (Look for documentation under the "NPSP Settings" path for Donations > Contact Roles).

Explanation:
The NPSP uses the Trigger Handler pattern (TDTM – Table-Driven Trigger Management) to manage all its triggers centrally. Instead of writing Apex triggers directly on objects, developers create an Apex class that implements the trigger logic, write a test class for it, and then register the class in the Trigger Handler custom object (npe01__Trigger_Handler__c). This allows the framework to dynamically enable/disable handlers without code deployment, making it highly configurable and upgrade-safe.

Correct Option:

B – Create the Apex class, test class, and Trigger Handler record
The Apex class must implement the npsp.TDTM_Runnable interface or extend npsp.TDTM_TriggerHandler.

A test class is mandatory (75%+ coverage) for deployment to production.

The Trigger Handler record registers the class, specifies the object, trigger action (Before Insert, After Update, etc.), order of execution, and active status.

This is the only supported, NPSP-safe way to add custom trigger logic.

Incorrect Option:

A – Create the Visualforce page, test class, and a Trigger Handler record
Visualforce pages are for UI, not for backend trigger logic. They have no role in TDTM customizations.

C – Create the Apex trigger, test class, and Trigger Handler record
Writing direct Apex triggers on NPSP objects (Account, Contact, Opportunity, etc.) is strongly discouraged because it bypasses TDTM and can break during NPSP upgrades.

D – Create the Lightning component, test class, and Trigger Handler record
Lightning components/Aura/LWC are client-side UI elements and cannot be used as trigger handlers in the TDTM framework.

Reference:
NPSP Developer Guide → “Custom Trigger Handlers Using TDTM”

Explanation:
This question tests knowledge of standard NPSP report types and their correct application. SYBUNT and LYBUNT are key metrics in fundraising. SYBUNT stands for "Some Year But Not This" year, identifying past donors who have not given in the current fiscal year. The scenario specifically asks about organizations, which in the Nonprofit Cloud data model are typically represented by the Account object, not Contacts.

Correct Option:

D. Customize the date range on the NPSP LYBUNT report for Accounts.
The question describes a classic LYBUNT (Last Year But Not This) scenario, not SYBUNT. It seeks organizations that gave last year (or any prior single year) but not the current year. The NPSP-provided LYBUNT report for Accounts is specifically built for this analysis. The consultant would customize the "Last Gift Date" range to define the "prior year" (e.g., last fiscal year).

Incorrect Options:

A. Customize the date range on the NPSP SYBUNT report for Accounts.
SYBUNT identifies donors who have given in any prior year (not just last year) but not the current year. While close, the question's emphasis on "some year prior to the current" aligns more precisely with the defined LYBUNT logic when focusing on the immediate prior year for reactivation campaigns.

B. Customize the date range on the NPSP SYBUNT report for Contacts.
This uses the wrong report type (SYBUNT vs. LYBUNT) and, more critically, the wrong primary object. The development director needs to analyze organizations (Accounts), not individual Contacts.

C. Create an Opportunity report that compares Contact donations from the previous fiscal year to the current.
This is a manual, complex approach that reinvents the wheel. It uses the wrong object (Contacts instead of Accounts) and would require custom cross-filters or formula fields. The built-in NPSP LYBUNT report provides this functionality instantly and accurately.

Reference:
NPSP Documentation: "Reports and Dashboards" and specifically the definitions and use cases for the standard LYBUNT and SYBUNT reports. These reports are fundamental to donor retention analysis in the NPSP.